Differences between the OpenEdge Adapter for Sonic ESB and the WSA
Although the OpenEdge Adapter for Sonic ESB and the WSA are very similar, there are some differences between them. The most significant difference is simply that the Sonic ESB hosts a service in conjunction with the OpenEdge Adapter for Sonic ESB, whereas a 4GL Web service is hosted on a Web server or Java Servlet Engine (JSE) in conjunction with the WSA.
It is important to note also that once installed, the OpenEdge Adapter for Sonic ESB does not appear as an entity of that name in any Progress or Sonic UI component. In the Sonic ESB Explorer, which is the primary tool for managing services and related functions, the presence of the OpenEdge Services node in the Services folder indicates that the OpenEdge Adapter for Sonic ESB is installed (see Figure 6–1).
There are a few additional differences, described in the sections that follow, that you should note if you are familiar with the WSA. The procedures to which these sections refer, as well as other important information about management of the adapters, is detailed in OpenEdge Application Server: Administration .
Service deployment and management
For a Sonic ESB service, once the AppServer application has been developed and its service definition has been generated, all deployment, configuration, and management activities associated with the service take place in the Sonic environment.
For a WSA-based service, you use the Progress Explorer or the WSAMAN Utility to perform deployment and administrative functions.
WSM and WSD file usage
When you install an OpenEdge service in the Sonic ESB environment, you specify one of two files as the service definition:
Sonic ESB stores a copy of the specified service definition file as a resource. The file retains its original name. The OpenEdge Adapter for Sonic ESB relies on the stored WSM or WSD file for the information needed to code and decode client SOAP messages and to access the appropriate service to execute requests.
When you deploy a Web service to a WSA instance, in contrast, the WSA stores the service definition as a copy of the original WSM or WSD file with the name FriendlyName.wsad. The WSA relies on this WSAD file for the necessary information about SOAP processing and service identification.
WSAD files do not exist in the Sonic ESB environment.
Storage of property information
Default run-time properties of OpenEdge services for Sonic ESB are hard-coded in the OpenEdge Adapter for Sonic ESB. To change these properties for a given service, you edit its associated WSM or WSD service definition file, which is stored as a resource in Sonic ESB as mentioned in the preceding section. You use the custom OpenEdge Resource Editor for this purpose.
In the WSA environment, default runtime properties are stored in the default.props file associated with each WSA instance. You can modify these properties for a given service by means of the Progress Explorer or the WSAMAN Utility. Each service’s runtime properties are stored in a file named FriendlyName.props.
The OpenEdge Adapter for Sonic ESB uses the OpenEdgeSrvType.properties file.
WSDL file generation
When your Sonic ESB service is ready for deployment, you use the custom OpenEdge Resource Editor available in the Sonic ESB Explorer to generate the associated WSDL file that defines the client interface to the service. This procedure differs from the corresponding procedure for WSA-based services in that the WSDL file for those services is generated through the Progress Explorer.